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Abstract. Efficient flight software development from natural language 
requirements needs an effective way to test designs earlier in the software 
design cycle. A method to automatically derive logical safety constraints 
and the design state space from natural language requirements is de- 
scribed. The constraints can then be checked using a logical consistency 
checker and also be used in a symbolic model checker to verify the early 
design of the system. This method was used to verify a hybrid control 
design for the suit ports on NASA Johnson Space Center’s Space Explo- 
ration Vehicle against safety requirements. 


1 Introduction 

Requirements are a part of every project life cycle; everything going forward 
in a project depends on them. Good requirements are hard to write, there are 
few useful tools to test, verify, or check them, and it is difficult to properly 
marry them to the subsequent design. In fact, the inconsistencies and errors in 
the requirements contribute greatly to the cost of the testing and verification 
stage of the project. For example, over 75% of the errors in flight software are 
introduced in the requirements and design stage, but most are found in the 
testing, verification, and maintenances stages of the project, when it costs 10- 
100 times more to correct them [1], 

This paper outlines a concept that formalizes the requirements and early 
design process by enabling verification during the requirements and early design 
stages of development and by linking the two stages together. Using natural 
language processing (NLP) tools and techniques combined with formal methods 
such as model checking to verify requirements and early design, it is possible to 
reduce the number of errors introduced during these stages, thus reducing the 
overall software and project cost. 

Requirements engineering is a difficult field because of the relative lack of con- 
straints on the requirement generator, which makes errors and inconsistencies 
likely. Several groups have tried to use formal methods to verify sets of require- 
ments. Current methods require NL requirements to be manually translated 
into a model or formal specification language for model checking. A specification 
notation called Software Cost Reduction (SCR) that is loosely based on event- 
driven logic can be used to find invariants in a model of the system described by 
the requirements (or mode machine) [2]. SCR has been translated to a format 



that works with Symbolic Model Verifier (SMV) and used with several projects 
[3,4]. A similar project that converted requirements written in Formal Tropos 
into Promela and verified them using SPIN was described in [5]. 

In this method, formal specifications in the form of logical statements are 
automatically created from sets of natural language (NL) requirements. The 
products that result from NLP of requirements are used in three ways. First, the 
specifications are checked for consistency by a novel set of tools that can con- 
vert and formally verify logical formulas. Second, the state space automatically 
derived from the requirements can be used by system designers during the early 
design stage to create a linear hybrid system model for the system [6]. Third, 
this model is verified against the formal specifications that were created from 
the requirements using a symbolic model checker, such as InVeriant [7]. 

A more complete description of the components of the tool chain can be found 
in Section 2. A small example of this design and verification method on the suit 
port design for the Space Exploration Rover (SEV) is described in Section 3 and 
Section 4 concludes the paper. 


2 Tool Chain Description 

The tool chain for this concept was developed from extensions to several ex- 
isting tools, such as the STAT (Semantic Text Analysis Tool) natural language 
parser, the SBTChecker (State Based Transitions Checker), a hybrid system 
design tool, and InVeriant, a symbolic model checker. This tool chain also incor- 
porates a novel tool that could be derived from several existing capabilities. A 
figure describing the tool chain is shown in Fig. 1. 



Fig. 1 : Tool chain description. 



2.1 STAT 


STAT was developed for analyzing problem reports, in which critical information 
is contained within data-fields of English-language sentences. STAT consists of 
a statistical parser, the Stanford Parser [8], which annotates a sentence; an al- 
gorithm, the minimal clausal reconstruction algorithm, that recognizes and fills 
empty categories in the parser’s output [9]; and a semantic interpreter that uses 
a lexical Aerospace Ontology [10]. 

This work uses STAT’s capability to parse and scope English-language sen- 
tences from a set of requirements into formal logic. The STAT software structures 
and annotates the text, and then produces the formal logic statements using a 
logic conversion module. STAT also has the capability to find state variables 
from the subjects of the sentences and a partial state space from the predicates. 

2.2 Logical Consistency Checker 

The logical consistency checker will be used to collect logical requirements and 
verify that they are all consistent given the appropriate state space rules. There 
are several existing tools that may be leveraged. SALT [11], for example, is 
a tool that creates logical statements from a highly specialized language that 
could be leveraged as an intermediate step between the STAT output and a 
formal LTL statement. Also, Spin [12] is capable of converting LTL formula to 
w-automata; it could convert the logical statements into a verifiable form and 
check the composed automata for consistency and logical errors. Novel work is 
concentrating on dealing with the inevitable state space explosion. 

2.3 SBTChecker 

The SBTChecker is a design tool that helps one create hybrid systems that have 
state-based transitions over a given passive (or uncontrolled) state space. Having 
state-based transitions is a property that significantly improves the ability to 
verify a system by reducing the effect of state space explosion [7]. 

Definition 1. Let T> = {di, d- 2 , ..., d n } be the set of passive state variables. Then, 
let T be the passive state space, T = A\ x A 2 x ... x A n . If for each state 7 i £ T, 
there exists some location, Vj € V , in the set of locations such that the passive 
state satisfies the invariant, 7* \= inv(vj), and each transition condition, 07 £ S, 
is based only on the passive states of the system, then the hybrid automaton has 
state-based transitions. 

A hybrid system is a set of concurrently executed hybrid automata. The 
SBTChecker can then be used to design individual automata that will be com- 
bined into a concurrent hybrid system. 

Theorem 1. If all controlled constraints on each state variable 27 £ X in each 
location Vj £ V„ are consistent, that is, able to be executed concurrently or 
merged, and if each automaton in the set of hybrid automata, H n £ TL,n = 
1 has state-based transitions over V n C V, then the composition, H' = 

Hi o ... o Hn, has state-based transitions over V. 



2.4 InVeriant 


The InVeriant software creates the locations and invariants from the set of 
concurrently-executed hybrid automata, checks consistency, and composes it 
with the unsafe set constraints to find unsafe locations. Then, based on the 
following theorem, the path to these unsafe locations depends only on the paths 
to the corresponding passive state values. 

Theorem 2. Given a hybrid system with a set of locations 14 = {vi,...,v n } 
whose transitions are based on the discrete states of a set of passively- constrained 
state variables T>k = {di , ..., d m }, if all the discrete states associated with each 
passive state variable are reachable from each other, then all locations Vi £ 14- 
are reachable from any other location, Vj £ 14 . 

The unsafe set is a collection of disjoint sets of constraints, Z = {£i, ..., ( n }, 
where each disjoint set of constraints, Q = {z\ , ...,z l n .j, has separate constraints 
on individual state variables, and each separate constraint z £ ( X d U X c U T>) x 
Q x (RUd) constrains a discrete controllable state variable (X d ), the rate of 
a continuous controllable state variable (A°), or a passive state variable. The 
verification algorithm simply composes the hybrid system’s locations with the 
unsafe set descriptions and checks the composition for consistency. If the compo- 
sition is valid, InVeriant takes steps to determine the reachability of the location, 
which is simplified by the state-based transitions property and Theorem 2. 

3 Preliminary Results 

The concept verification procedure was implemented on the suit port state ma- 
chine for the SEV. The SEV is a next-generation modular concept vehicle in- 
tended to be used in a variety of target environments including the moon, Mars, 
or even an asteroid. The current generation consists of an enclosed cabin mounted 
on a wheeled chassis. The cabin is designed to allow two crew members to live 
and work in shirt sleeves for up to two weeks; two spacesuit ports enable the 
crew to easily exit the cabin for extra- vehicular activity (EVA). 

The suit port consists of an inner and outer hatch (the inner one is actuated, 
the outer one is connected to the suit), a seal around the suit (PLSS) and an 
actuated Marrnon to secure the suit in place. The vestibule is the area between 
the inner and outer hatches. The passive state variables and their corresponding 
state values are listed in Table 1. 

The transitions between the states in the passive state space are all considered 
to be stochastic with trivial models (valid transitions occur between all states). 
There are two exceptions; the first is the pressure status state variables, which 
have linear discrete models that are based on real continuous values. The second 
exception is the Command state variable; the model for this is shown in Fig. 2. 
This model is generated from the requirement that it must be possible to safely 
initiate ingress or egress from any point in the procedure. 

The first design of the hybrid control state machine for the suit ports was 
designed using the SBTChecker, and therefore has state-based transitions. The 



Table 1: Passive State Variables 


State Variable 

Abbreviation 

States 

Suit/ Vestibule Pressure Status 
Suit Status 

Hatch/Marmon Health 
Hatch/PLSS Seal/Vestibule Leak 
Command 

SP/VP 

ss 

HH/MH 

HL/PL/VL 

CM 

EVACUATED, LOW, EQUALCABIN, HIGH 
ATTACHED, DETACHED 
NOMINAL, JAMCLOSED, JAMOPEN 
VERIFIED, FAILED, UNKNOWN 
HOPEN, HCLOSE, MOPEN, MCLOSE 



Fig. 2 : Model for the Command state variable for the suit port verification example 

flow of a nominal egress would follow the path shown in Fig. 3 a; the flow of a 
nominal ingress would follow the path shown in Fig. 3 b. 

Four natural language safety requirements were run through STAT. These 
requirements were the following: 

1. The hatch shall remain closed unless the Marmon is closed, the PLSS seal 
is verified, and the vestibule pressure is equalized with cabin. 

2. The Marmon shall remain closed unless the hatch is closed, the hatch seal 
is verified, and the vestibule is evacuated. 

3. The hatch shall be closed whenever the suit is detached. 

4. The hatch must be closed whenever the suit pressure is not equalized with 
the cabin. 

The STAT tool output the requirements in xml form, which were used di- 
rectly in the input file for the InVeriant model checker. The state machine and 
the safety requirements were run through InVeriant, which found several places 
where the unsafe set as specified by the safety requirements was reachable. Both 
the requirements and the hybrid control system were redesigned and the new 
design and requirements were verified against one another to ensure quality and 
correctness. 

4 Conclusions and Future Work 

The formal early design and verification concept presented here has many bene- 
fits. Automatically converting natural language requirements into a formal spec- 


a) Egress 

CM == HOPEN ^ CM == HCLOSE CM==MOPEN 

I Hatch Leak Check | ^ | Open Hatch | ^ | Close Hatch | » | Marmon Leak Check pj Open Marmon 

b) Ingress 

J/2M == MCLO SE 

| Close Marmon | » | Hatch Leak ChedT~| Open Hatch | Close Hatch | 

CM == HOPEN CM == HCLOSE 


Fig. 3 : Nominal execution flow for a) egress and b) ingress 


ification that can be checked for consistency and subsequently used in a verifica- 
tion algorithm will reduce the number of errors introduced in the requirements 
and early design stages. Likewise, formally tying the requirements and early de- 
sign together will ensure a better design. Currently, work is underway on adapt- 
ing STAT to pull state space information from natural language requirements, 
on leveraging tools to design a logical consistency checker, and on understanding 
the classes of requirements and systems that can use this method. This concept 
will be tested on sets of requirements for other flight products at NASA-JSC, 
including the SAFER project. 
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